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Developer Perspective 

Engineering: 

manage compiexity, scaie, iifetime 
increase quaiity 
reduce defects 

reduce maintenance and support costs 
reduce time-to-market 


reuse successfui soiutions 
appiy methods and toois 
iterate and optimize 



User Perspective 

Usabiiity: 

meets needs 

increase productivity 

easy to iearn 

effective to use 

reduce errors 

safe to use 



User Perspective 

Experience: 

satisfying 

motivating 

iooks nice 

enjoyabie 

fun 
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Meeting Needs 

Verification 

making sure you deveiop the system right 
(i.e., according to the requirements) 
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Discussion 


Question: 

What are some major activities in deveioping software? 



Question: 

is there an effective order on these activities? 
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Waterfall 


Discussion 

Question: 

What are some pros and cons of the 
waterfaii modei? 
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Waterfall 


Pros: 

easily understood 
enforces discipline 



Waterfall 


Cons: 

uses a manufacturing view of software 

• most software is not made as a "final" product 


verification at every phase customer must be patient 

documentation • but time-to-market is critical 

customer sees the system only at the end 
• may not satisfy their real needs 
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Waterfall 


Cons: 

dependence on requirements being "right” 

• could end up building the wrong system 
requirements must all be known up front 

• but cannot always foresee all the requirements 



Prototyping 
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Summary 

need to be able to iterate 
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^ Meeting Needs 

Validation 

making sure you develop the right system 
(i.e., what the customer really wanted) 




Prototyping 

Iterative design: 

cycling through several designs, improving the product 
with each pass 


Various approaches (in combination): 
throwaway 

incremental 

evolutionary 
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Throwaway Prototyping 

Process: 

build and test prototype 

gain knowledge for the real product 

"throw away" the prototype 



Throwaway Prototyping 

Pros: 

more communication between users and developers 
functionality is introduced earlier, which is good for morale 


then "develop" the product for real 
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^ Throwaway Prototyping 

Cons: 

building the prototype must be rapid 

some qualities may be sacrificed, 
like security, reliability, etc. 




Incremental Prototyping 

Process: 

triage system into separate "increments" 

• i.e., "must do", "should do", "could do" 
develop and add one increment at a time 


temptation to use the throwaway prototype in the final 
product 


Example (accounting system): 
prototype 1 — general ledger 

prototype 2 — accounts receivable/payable 

prototype 3 — payroll 
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^ Evolutionary Prototyping 

Process: 

feature is refined or "evolved" over time 



Example (text editor): 

prototype 1 — command key cut/paste 

prototype 2 — undoable cut/paste 

prototype 3 — drag and drop cut/paste 



Other Kinds of Prototypes 

User interface sketches 

hand drawn or using drawing tool 


Storyboards 

graphical depiction of user interface 
like a comic strip 
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other Kinds of Prototypes 

Index cards, Post-It® notes 
e.g., tasks In a project plan 

e.g., classes in an object-oriented analysis 

e.g., pages in a web site structure 



Other Kinds of Prototypes 

Physical mockups: 

e.g., made out of wood, clay, or foam 
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Other Kinds of Prototypes 

Wizard of Oz: 

"Pay no attention to that man behind the curtaini" 



feature is actually "implemented" through human 
intervention "behind the scenes" 


Staged Delivery 
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staged Delivery 

Developers: 

deliver the system in a series of working releases or builds 
Users: 

use some functionality while the rest continues to be 
developed 


Possible parallelism: 

production and development systems 

staggered development streams 



Staggered Builds 


deliver build i 



deliver build i+2 
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^ Staged Delivery 

Pros: 

provides more options 
different builds focus on specific features 




Staged Delivery 

Cons: 

overhead needed to plan and drive the product toward 
staged releases 


extra complexity of supporting multiple versions in the 

reduces estimation errors 
risks are reduced earlier 
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Microsoft Daily Build 

Process: 

software product is built every day 



Microsoft Daily Build 

Testing: 

if the build breaks (not runnable nor testable), the whole 
process is stopped until the problem is found 


build cycle becomes the heartbeat of the project; everyone 

knows the status failures detected during testing are available and 

broadcast next morning 


built system must be runnable for overnight testing 


huge incentive not to break the build 
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Unified Process 
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Unified Process 


Link: 

http://en.wikipedia.org/wiki/Unified_Process 

Phases 

^ |jETai30TatTDrr|jConstructionyTransition | 

Business Modeling 

Requirements ^ _ 

Analysis & Design 
Implementation 
Test 

Deployment 
CM and SCS 
Project Mangemen^ 

Environment ^ 
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Iterations 

This Unified Process diagramj 
shows different disciplines 
are used at different times. 


stakeTiolder 
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Unified Process 

* Iterative 

* Incremental 

* Customizable 

* Phases 

* Inception: Risks and Business Cases 

and Use Cases 

* Elaboration: use case diagrams and 

class diagrams 

* Construction Phase: implementation 

in iterations 

* Transition: Deployment 


Unified Process 



Agile Practices 



“Agile Manifesto" 

Link: 

http://agilemanifesto.org/ 
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Agile Principles 

"Individuals and interactions": 
trust motivated individuals 

face-to-face conversation 



Agile Principles 

"Working software": 

the main measure of progress 

continuous, frequent delivery of value 


best work emerges from self-organizing teams 
team reflects on and adjusts their behavior 


promote constant, sustainable pace 
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Agile Principles 

"Customer collaboration": 

customers and developers work together 

satisfy customer early 



Agile Principles 

"Responding to change": 

welcome changing requirements, even late 


technical excellence and good design 
simplicity—art of maximizing work not done 
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extreme Programming (XP) 

Link: 

http://www.extremeprogramming.org/ 



XP 


Phiiosophy: 

communication 

feedback 

simpiicity 


programmer friendiy 
code-centric 

for smaii teams (up to about 20) 


requires courage 
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XP 

12 practices: 


40 hour week 


metaphor 

simple design 

collective 

ownership 

coding standards 


smaii reieases 
continuous integration 
refactoring 



XP 


For programmer weifare: 

"40 hour week" 

• work no more than 40 h a week 

• never work overtime a second week in a row 


pianning game 
testing 

on-site customer 


pair programming 
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XP 


For shared understanding: 
"metaphor" 


• guide deveiopment with a shared story of how 
the system works 



XP 


For shared deveiopment: 

"coiiective ownership" 

• anyone can change any code anywhere in the 
system at any time 


"simpie design" 


"coding standards" 


design the system as simpiy as possibie; 
remove extra compiexity when discovered 


write aii code according to ruies that enhance 
communication and understanding through 
code 
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XP 


For continuity: 

"smaii reieases" 

• put simpie system into production quickiy, then 
reiease new versions on a very short cycie 



XP 


For feedback: 

"pianning game" 

• determine scope of the next iteration and 
overaii reiease together with customer 


"continuous integration" 

integrate and buiid the system many times a 
day 


"refactoring" 

restructure the system to improve its design, 
simpiicity, or fiexibiiity 


"testing" 


• write automated unit tests first before the code; 
customer writes tests in requirements 


"on-site customer" 

• inciude reai, iive user on the team, avaiiabie 
fuii-time to answer questions quickiy 
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XP 


Discussion 



For synergy: 

"pair programming" 

• have aii production code written with two 
programmers activeiy at one machine 


U Question: 

Why shouid programmers work in pairs? 
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Pair Programming 

Synergies: 
more ideas 


• compiementary skiiis 

• better consideration of aiternative soiutions 



Pair Programming 

Synergies: 

pressure 


• they do not want to iet each other down, or 
waste each other’s time 


iearning 


courage 


expert/student apprenticeship 
continuous critique to iearn new things 


they give each other confidence to do things 
they might avoid if aione 


Pair Programming 

Synergies: 

reviews 


• better abie to reveai defects with more eyes 
iooking at the code 



debugging 


• bugs reveai themseives when one expiains the 
misbehaving code to the other 


XP 


So why is it caiied "extreme"? 
if short iterations are good, 
make them reaiiy short 

if simpiicity is good, 

make the simpiest thing that works 

if design is good, 

do it aii the time (refactoring) 

if testing is good, write tests first, and 
do it aii the time (test-driven deveiopment) 

if code reviews are good, 

do it aii the time (pair programming) 


Scrum 

• Agile Process 

• Doesn't prescribe many development 
methods 

• Based around 

• Feedback 

• Roles 

• Meetings 

• Prioritization and Planning 

• Scrum is like classic engineering 
management processes and is often 
used onsite in civil engineering. 



Scrum Roles 

• Scrum Master 

• Process Master, protects the 
team and helps the team follow 
scrum 

• Product Owner 

• Represents the customer 

• Team members 


Scrum Meetings 

• Planning Meeting (1 per iteration) 

• Daily Scrunn ( nnany per iteration) 

• Review (1 per iteration) 

• Retrospective (1 per iteration) 

stories and: 

- Choose appropriate stories to 
work on next 

- Estinnate their cost in tinne 

- Prioritize thenn 

- Fit thenn into the tinne left for 
the iteration. 




Scrum Meetings 

• Planning Meeting 

• First nneeting of the iteration (1 
day) 

• Take requirennents and user 


Scrum Meetings 

• Daily Scrunn 

• Also the daily standup 

• Everyone stands up so that they 
are unconnfortable and want to 
finish soon 

• Tinne linnited 

• Every teann nnennber answers 3 
questions: 

- What did you do? 

- What are you going to do? 

- What is blocking you? 


Scrum Meetings 

C » Retrospective 

• Review issues faced with quality 
and personal 

• Try to innprove the process 
• What went well? 

• What could be innproved? 

• Stay Cainn 
• Review 

• Review work connpleted 
• Review work not connpleted 
• Dennonstrate current systenn 



Some Scrum in the lab 

• I define my user stories in a text file. 

• I act as the product owner, and tell the team 
what I want to see. 

• The team decides what to work on next. 

• Every day I ask my research assistants: 

• What did you do since last time? 

• What are you going to do? 

• What do you need from me? 

• We don't explicitly prioritize 

• We don't explicitly plan 

• We don't have multiple iterations 

• Why not? Because we are experimenting 
and cannot plan more than a week ahead. 



More Information 


Articles: 

"A Rational Design Process: 

How and Why to Fake It" 

• D. L. Parnas and P. C. Clements 

• IEEE TSE, 12(2), 1986 


"Software Development Worldwide: 

The State of the Practice" 

• M. Cusumano, A. MacCormack, 

C. F. Kemerer, and W. Crandall 

• IEEE Software, November/December 2003 



More Information 


Articles: 

"How Microsoft Builds Software" 

• M.A. Cusumano and R.W. Selby 



More Information 


Books: 

Software Project Survival Guide 
• S. McConnell 


• Comm. ACM, 4(6), 1997 


Microsoft Press, 1998 


The Build Master 

• V. Maraia 

• Addison-Wesley, 2005 
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_ More Information 



Books: 


Extreme Programming Explained 


• K. Beck 

• Addison-Wesley, 2004 

Pair Programming Illuminated 

• L. Williams and R. Kessler 

• Addison-Wesley, 2002 
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